Chip 1996 April/CHIP 1996 aprilis (CD06).zip/CHIP_CD06.ISO/hypertxt.arj/92/WIRTH.CD

Text File | 1995-09-17 | 29KB | 488 lines

      @V""A dolgokat nevükön kell nevezni" (Niklaus Wirth)@N

          Világos alapelveket követve alakította ki Niklaus  Wirth
      --  a  ""strukturált  programozás  atyja"  --   legfiatalabb
      gyermekét,  az  Oberon  rendszert  is.  A  Borland   Európai
      Szoftverfesztiválján meginterjúvoltuk az egzakt  informatika
      legjelentôsebb tervezôjét.
          @K-- Hogyan értékeli a Borland Európai Szoftverfesztiválja
      @Kalatt a számítógéprôl és kultúráról folyt beszélgetéseket?@N
          --  Nagyon   örülök,  hogy   alkalomadtán  a   technikai
      vonatkozások  is megvitatásra  kerülnek. A  számítástechnika
      kétségtelenül  befolyásolja  a   gazdaságot  és  ezáltal   a
      társadalmat. De  én egy  kissé szkeptikus  vagyok -- szemben
      azokkal  az  emberekkel,  akik  erôsen  beleélik  magukat  a
      jövôrôl alkotott látomásaikba, és a csillagos eget is nekünk
      ígérik. Ami  Minsky úr  vízióit illeti,  az egyetlen tanács,
      amit szerintem adni lehet, és  amit én is követek: nem  kell
      ôt  annyira  komolyan  venni, tekitsük  inkább  úgy,  hogy ô
      játszik.
          Tûnôdjünk el azon, hogy mely területekre hatott igazán a
      számítástechnika. A  tisztán katonai  céloktól eltekintve  a
      kutatásban  lelhetô  fel  a  hatása:  manapság  egészen  más
      eszközeink   vannak  arra,   hogy  természeti   jelenségeket
      kutassunk,  és  ezeket   az  eszközöket  megépítésük   elôtt
      számítógépben szimuláljuk.  Ha olyan  konstrukciókat akarunk
      szimulációval   kipróbálni,   amelyeknek   nincs    egységes
      matematikai  leírása,   akkor  ennek   természetesen  óriási
      elônyei vannak.
          A számítógép további  fontos felhasználási területei  az
      igazgatási  és  bankügyletek,  esetleg  még  a   közlekedési
      eszközök.  De ezeken  a szektorokon  kívül még  nem  nyomult
      annyira elôre a  számítógép, hogy pótolhatatlan  lenne. Sôt,
      néha  az  az  érzésem,   hogy  a  számítógépet  csak   azért
      használják,  mert   ""modern".  Olyan   tevékenységekhez  is
      alkalmazzák,  ahol  a   régebbi  módszerek  is   tökéletesen
      megfelelnének.  Emiatt sok  teljesen felesleges  kötöttségre
      teszünk   szert.   Különösen   akkor   látszik   ez,  amikor
      elveszítjük  az  uralmunkat  a  képernyô  mögötti történések
      felett. Jó, ez  mindenhol így van,  a háztartásban is:  ha a
      hûtôszekrény tönkremegy, akkor hívnunk kell egy szerelôt. De
      egy  hûtôszekrény   sokkal  egyszerûbb   készülék,  és   sok
      hûtôszekrény-szerelô  van. Tehát  nem félünk  attól, hogy  a
      hôségben hûtôszekrény nélkül maradunk.
          Ha azonban a számítógépen nem úgy mûködik valami,  ahogy
      kell,  és bár  legyen ez  csak a  szoftver hibája,  akkor  a
      komputerhasználók 99 százaléka áll  mint szamár a hegyen.  E
      függôséget valószínûleg nem lehet elkerülni, de  tisztáznunk
      kell,  hogy a  számítógépre annyira  nagy szükségünk  van-e,
      hogy vállalnunk kell ezt a függôséget.
          @K--  Kapcsolatban   van  ez   a  függôség   egy  bizonyos
      @Kprogramtípussal,   amely   feleslegessé   teszi,   hogy    a
      @Kfelhasználó is használja a fejét?@N
          -- Minden rendszer sok szintbôl áll. Erre egyszerû példa
      a  következô:  a  munkahelyükön  szövegszerkesztôt  használó
      titkárnôknek  érteniük  kell  a  szövegszerkesztés alapjait.
      Tudniuk kell, hogy a szövegnek milyen a struktúrája ebben az
      alkalmazásban.  A  felhasználónak  tudnia  kell,  hogy  mi a
      szöveg. De azt már nem kell tudnia, hogy a számítógép hogyan
      kezeli  a  szöveget  vagy  azt,  hogy  milyen  az  operációs
      rendszer felépítése. A rendszereink ebben az értelemben  még
      nincsenek elég jól megszervezve.  Ha valami nem megy  jól --
      és ez sajnos gyakran megesik --, akkor a felhasználó ott áll
      tehetetlenül, mivel nem tud a kezelési felület mögé nézni --
      amit  persze  nem  is  szabadna  megtennie.  Ezután  hív egy
      szakembert, akinek többnyire  szintén nincs meg  a szükséges
      tudása, mivel  a programot  esetleg az  USA-ban készítették.
      Egy hûtôszekrénnyel nem történhet ilyesmi, mert a szerelôket
      kiképezték, így minden problémával meg tudnak birkózni.
          @K--  A  szaklapokban ellentét  alakult  ki a  strukturált
      @Kprogramozás (például a Pascal) hívei és az objektumorientált
      @Kprogramozás (például a C++) követôi között. Milyen  szerepet
      @Kjátszik ebben a típusellenôrzés?@N
          -- Én  nem nevezném  ezt ellentétnek.  A Pascal lényeges
      vonása  az  adattípusok  koncepciójának  bevezetése.  Minden
      objektumnak -- legyen  az változó, paraméter,  függvény vagy
      konstans   --    van   egy    típusa,   amely    látható   a
      programszövegbôl.  îgy  a  programozó  ellenôrizheti,   hogy
      ésszerûen kapcsolja-e  össze a  típusokat, a  fordítóprogram
      (compiler) pedig leellenôrizheti azt. A C-ben nincs meg ez a
      tulajdonság,   és   az   assembly   kódban   sincs.   Itt  a
      programozónak  döntenie  kell:   meg  akarom-e  tartani   az
      assembly kód  vagy a  C rugalmasságát,  vagy olyan rendszert
      akarok,  amely  ismeri a  típusokat?  Ebben nincs  ellentét,
      viszont két különbözô osztályról van szó: egy magasabbról és
      egy alacsonyabbról.
          A  típuskoncepció  nagyon  lényeges  dolog.  A  C++  a C
      kibôvítése  objektumorientált  struktúrákkal,  és némiképpen
      meghonosították benne a típuskoncepciót is. De véleményem és
      meggyôzôdésem  szerint   itt  nincs   középút,  hanem   vagy
      használunk típusokat vagy nem.  A C++-ban ez nincs  megoldva
      tisztán.   Fontos,   hogy   a   számítógép   valóban  mindig
      ellenôrizhesse,   hogy   a   típusok   összeegyeztethetôsége
      (kompatibilitása)  teljesül-e. Mindig  az derül  ki, hogy  a
      hibák ott vannak, ahol nem sejtjük ôket. Az Oberon-rendszert
      szinte  teljesen  az  Oberon  nyelven  írtuk,  amely  teljes
      típusokat használ.  Csak egy-két  apróságot írtunk  assembly
      nyelven. Assembly szinten  nincsenek típusaim, tehát  tudom,
      ha hibát követek el, akkor nehéz lesz megtalálni.
          Még egy  szót az  objektumorientáltságról: az  Oberonban
      elkerültük az olyan új fogalmak bevezetését, mint  objektum,
      osztály,  jelentés és  módszer. Megmutatjuk,  hogy ezek  már
      léteznek  az  eljárásokra  épülô  (procedurális) programozás
      világában. Tehát nem lépünk  be egy új világba,  és tévedés,
      hogy   a   megtanult  dolgokat   félre   kell  tennünk.   ùj
      programozási technikákat tanulunk  -- de eddigi  ismereteink
      alapjain.
          Az   objektumorientált    programozás   kiegészült    az
      osztályokkal és alosztályokkal. Az osztályok nálunk típusok.
      Az Oberonnál -- a Pascalhoz  és a Modulához képest --  ehhez
      még hozzájön  a típusok  bôvítésének lehetôsége.  A bôvített
      típus az alosztály.  Minél több tulajdonságot  illesztek be,
      annál  több  korlátozással   kell  számolnom.  Például:   ha
      állatokról beszélek, akkor az a típus, hogy ""állat", nagyon
      általános.  Van  még  az  emlôsállatok  alosztálya, amelynek
      leírásához   néhány,   erre   az   alosztályra  korlátozódó,
      specifikus tulajdonság kell. Nekünk is valami ilyesmink van.
      Az objektumorientált világban az alosztály olyasvalami,  ami
      az eddigi alapokon is lehetséges. A ""típus" egy nagyon régi
      fogalom a matematikában.  Ezzel szemben az  ""osztály" nincs
      ilyen tisztán definiálva.
          @K-- Ezért nevezte  ezt a mechanizmust  ""típusbôvítésnek"
      @Kés    nem   ""örökségnek",    mint   az    objektumorientált
      @Kszóhasználatban?@N
          --   Igen.   Mindig  fenntartással   fogadom   az  olyan
      antropomorf  kifejezéseket,  mint az  ""örökség".  Senki sem
      halt meg.
          @K-- Ön szerint  van generációváltás a  programozók között
      @K--  tehát  van-e olyan  új  generáció, amely  képzettségébôl
      @Kadódóan más fogalmakat használ?@N
          --  Az  új  ötleteket  kétségtelenül  mindig  a fiatalok
      fogadják be  elôször és  viszik át  a gyakorlatba.  Ez már a
      Pascalnál is így volt.  Az öreg rókák gondolkozását  már nem
      lehet  megváltoztatni.   Tíz  évet   fektettek  abba,   hogy
      elsajátítsanak valamit -- és akkor jön valaki, és el  akarja
      tôlem venni azt a gépet, amelynek minden részletét  ismerem.
      Az  embereket  nem   kellene  feltétlenül  új   jelszavakkal
      megnyerni, hanem maradhatnánk  a tárgyilagosság talaján.  Az
      elméleti képzés során kellene  a dolgokat nevén nevezni,  és
      arra  építeni,  amit  már  ismerünk.  A  matematikának nincs
      kereskedelmi háttere. De a számítástechnikában nagyon erôsen
      uralkodnak  a  kereskedelmi  érdekek,  és  az  új gondolatok
      jobban meghallgatásra találnak.
          @K--  Az Oberonban  Ön búcsút  mondott a  programnak és  a
      @Kprogramfutásnak. Helyére modulok és eljárások léptek.@N
          --  Ez  független   a  programozási  nyelvtôl,   itt  az
      operációs  rendszerrôl van  szó. A  kettô között  világos  a
      határ például a Modulában, vagy akár az Adában. Itt a  modul
      egyrészt  egy  olyan  szöveges  egység,  amelyet  a compiler
      egyszerre fel tud dolgozni.  Másrészt a modul a  tevékenység
      egysége. Meg lehet hívni vele egy programot.
          Az  Oberonban  világosan  elkülönítjük  a  fogalmakat: a
      modul  egy szöveges  egység, amelyet  a compiler  mellékesen
      külön  is  feldolgozhat.   De  a  számítógépen   elindítandó
      tevékenységnek nem kell feltétlenül azonosnak lennie  azzal,
      ami  szöveges  egységgel   van  leírva.  Ebben   a  szöveges
      egységben, a modulban ennyi  meg ennyi változó és  annyi meg
      annyi eljárás van, amelyek másutt is felhasználhatók, vagyis
      exportálódnak. Az eljárásokat egyenként meghívhatjuk. Ha  ez
      a  -- néha  igen rövid  -- tevékenység  befejezôdik  egy-két
      ezredmásodpercen belül, akkor újra miénk az ellenôrzés.  ùgy
      is  mondhatjuk,  hogy  mindvégig  egyazon  programon   belül
      vagyunk.
          Ha  ezzel  szemben  elindítok  egy  programot,  akkor  a
      program  belép  egy módba.  Ennek  legjobb illusztrációja  a
      következô: ha egy hagyományos MS-DOS-számítógéppel dolgozunk
      fel  egy  szöveget,  akkor  elôször  belépünk  az  operációs
      rendszerbe,  aztán  meghívjuk  az  EDIT  programot.  Az EDIT
      átvisz  minket  egy  másik,  sajátos  környezetbe,  ahol más
      szabályok érvényesek. Most a  szöveg már nem parancs,  hanem
      valami begépelendô dolog.
          Az Oberonban nincs ilyen.  Nem az egyik módból  lépünk a
      másikba, hanem rövid mûveleteket indítunk, amelyeknek nagyon
      sokféle  lehet  a  hatóereje.  Mûvelet  lehet  egy  karakter
      begépelése vagy egy szó  kiválasztása az egérrel --  valami,
      ami azonnal végbemegy --, de lehet egy szimuláció is,  amely
      24 órán keresztül tart.
          @K-- Az MS-DOS-ban  például különbözô módokban  mozgok. Az
      @KOberonnak ezzel szemben tökéletesen állandó felülete van. Ez
      @Ka koncepció megváltoztatása?@N
          -- Inkább azt mondanám, ez a szervezés  megváltoztatása.
      Ez  egy  másik  tudatot  eredményez  a  használat  során. Ez
      lényegesen hozzájárul az  egyszerûbbé tételhez. A  hozzá nem
      értôk számára  nagyon zavaró  a lépkedés  az egyik  módból a
      másikba.  A felhasználónak  fejben kell  tartania, hogy  hol
      van,  és mi  zajlik az  adott módban.  Mindez most  elmarad.
      Bizonyos értelemben állapotok állnak rendelkezésünkre,  ezek
      azonban mind láthatók és nincsenek elrejtve. Ez  egyszerûbbé
      teszi a használatot.
          @K-- Az asztali  számítógépek operációs rendszereiben  már
      @Kévek óta használnak hasonló kezelési felületeket, például  a
      @KMacintoshon.  Miért  van  most  szükség  más  felületre,  az
      @KOberonra?@N
          -- Vannak  ablakaink is,  amelyek azonban  nem fedik  át
      egymást, bár ez részletkérdés. Az Oberon alapötlete a  Xerox
      @KCedar@N-jától  jött.  Itt  felosztjuk  a  képernyôt, átfedések
      nélkül.  Az  elôugró  (pop-up)  menüknél  sokkal rugalmasabb
      megoldást találtunk, mivel tetszôleges szövegben megadhatunk
      parancsokat. Szöveget outputként is létrehozhatunk, aztán  a
      parancsokat      kijelölhetjük      az      egérrel.       A
      ""levélszekrényembôl" kivehetem  egyik kollégám  jelentését,
      aki  azt  írja  nekem,  hogy  új  parancsokat  készített   a
      rendszerhez.  ï  a  jelentéshez  hozzákapcsolhatja  ezeket a
      parancsokat, s nekem  csak ki kell  jelölni ôket az  egérrel
      ahhoz, hogy kipróbálhassam.
       Elôugró menükre is van lehetôség. Ezeket az egyik csomagban
      használtuk   fel,   és  tool-okként   hozzáférhetôk.   De  a
      szövegekben lévô parancsok rugalmasabbak. Az ikonokat, a kis
      képeket nem használjuk: úgy  gondoljuk, hogy az írás  sokkal
      kifejezôbb, jellemzôbb és  pontosabb. Ha csak  egy keresztet
      és egy fejet látok, akkor többnyire nem tudom pontosan, hogy
      mit jelent. Ezzel szemben  a szövegben ez egészen  világosan
      ki van fejezve. Még egy mellékhatás: a számítógépes világban
      régebben  is és  még ma  is uralkodik  rajtunk a  rövidítési
      mánia,  az összes  betûszóval és  hárombetûs szóval  együtt.
      Ettôl  mi messzemenôen  eltávolodtunk. Mi  kiírjuk a  teljes
      szót  angolul  (vagy  éppen  németül).  A  szavakat  már nem
      gépeljük be, hanem  gyorsan lemásoljuk ôket.  Hiszen valahol
      már megvannak  a dokumentumban.  A begépelés  tulajdonképpen
      alárendelt szerepet játszik, tehát írhatjuk úgy a  szavakat,
      hogy mindig megértsük, mit jelentenek. Ez haladás a kezelési
      felületben, nem pedig a világ gyermeteggé változtatása.
          @K-- ùgy érti, hogy az ikonok gyermetegek?@N
          --  Véleményem  szerint  igen.  Alapjában  nem szeretném
      lebecsülni a  képeket, de  sosem arra  törekedtünk, hogy  az
      óvodások számára készítsünk számítógépes rendszereket, hanem
      olyan emberek számára, akik tudnak olvasni, és megértik azt,
      amit  olvasnak.  Nekem  úgy  tûnik,  hogy  az  ikonok  nem a
      megfelelô utat  jelentik. Egy  bizonyos bonyolultság  felett
      inkább zavarják, mint könnyítik a megértést. Ráadásul ezek a
      díszítmények  elég  költségesek.  Ma  már  alig  lehet olyan
      számítógépet venni,  amelynek 1  Mbyte-nál kisebb  memóriája
      van. És ha  mégis veszünk egy  ilyet, akkor nem  tudunk vele
      mit kezdeni,  mivel a  szoftverek több  Mbyte-ot igényelnek.
      Értesítést  kaptam  egy  kaliforniai  kutatólaboratóriumtól,
      hogy operációs rendszerük új  kiadásával minden gép kap  egy
      memóriabôvítôt. îgy minden gépnek már 64 Mbyte-os  memóriája
      van.   A   mi   rendszerünk   rugalmassága   a  kereskedelmi
      rendszerekéhez hasonló, de nekünk pár száz Kbyte is elég.
          Valóban minden  rendszernek Mbyte-okra  van szüksége  az
      ésszerû   alkalmazásokhoz,   vagy  pedig   képekre   és  más
      felesleges díszítményekre megy el a memória? Érdekes módon a
      vevôk  készek  megfizetni  a  díszítményeket.   Valószínûleg
      azért, mert nem tudják, hogy másképp is lehet.
          @K-- Ön szerint ez csak egy divatjelenség?@N
          -- òvatos vagyok a jóslásokkal. Hiszen nagyon sok  olyan
      ember van, aki szereti  ezeket a dolgokat. A  Windows nagyon
      vonzó megjelenésû. Vannak egymást átfedô ablakok,  különféle
      színek, a háttérben egy szép lány, és így tovább. Ha azonban
      az ember  tényleg meg  akarja ismerni  a számítógépet,  vagy
      dolgozni akar  vele és  nem játszani,  akkor nincs  szüksége
      ilyesmikre.
          @K-- Éppen a számításigényes feladatoknál lenne  kívánatos
      @Kegy folyamatot  a háttérben  futtatni. Ön  azonban az Oberon
      @Kesetében egy  egyprocesszoros multitasking-rendszer  mellett
      @Kdöntött. Miért?@N
          --  Ezáltal   egy  csomó   problémát  távol   tartottunk
      magunktól. Jürg Gutknecht és én találtuk ki, és magunk írtuk
      meg a rendszert. ïrültség, hogy egy kétfôs csapat mellékesen
      készített el  ilyesmit. Volt  más elintéznivalónk  is. Ha  a
      multitaskingot  is beleépítettük  volna, akkor  valószínûleg
      még ma sem lennénk készen. Az szörnyen bonyolítja a  dolgot.
      Számomra úgy tûnik, hogy  egyre inkább az az  irányzat, hogy
      nagy  háttérmunkát  végeztetünk  egy  szerverrel.   Szívesen
      elismerem, hogy ez természetesen nagy pazarlás, mivel a  gép
      állandóan  fut.  Másrészt  ma  már  óriási  feleslegünk  van
      processzor-teljesítménybôl. Szerintem a fejlôdés afelé tart,
      hogy minden folyamatnak  külön processzora legyen.  Hiszen a
      processzorok ma már nagyon olcsók.
          A szerver egy szobában  áll, és egyik feladatot  a másik
      után  hajtja  végre. Ha  valósidejû  (real-time) rendszerrel
      dolgozunk, akkor ez természetesen  nem viselhetô el. De  sok
      más, Oberonban nyújtott dolog sem feltétlenül szükséges.  Az
      nem  járható  út,  ha  ugyanazzal  az  operációs rendszerrel
      akarunk mindenkit optimálisan kielégíteni.
          @K-- Minden alkalmazáshoz más operációs rendszer kellene?@N
          --  Az  a  fogalom is  megingott  kissé,  hogy operációs
      rendszer.  De hát  mi az  Oberonban az  operációs  rendszer?
      Modulok hierarchiája. Filozófiánk azt mondja, hogy lehetôleg
      kevés ilyen modul legyen az alaprendszerben. A  felhasználók
      maguk  építik  fel  saját  hierarchiájukat,  amelyre   éppen
      szükségük van.  Ha például  elindítják a  szövegszerkesztôt,
      akkor automatikusan az ahhoz szükséges modulokból épül fel a
      hierarchia. A többi modul nem marad a memóriában. Az  óriási
      memóriákra  azért van  szükség, mert  sok esetben  a kód  95
      százaléka   egyáltalán   nem   kerül   felhasználásra,    de
      automatikusan az  is bekerül  a memóriába.  Nálunk nem  ez a
      helyzet.
          @K--   Miért   használta   fel   újra   az   Oberonban   a
      @Kszemétgyûjtési (garbage collection) technikát?@N
          --  A  programozók  számára  ezáltal  sok  helyzet válik
      lényegesen egyszerûbbé. A programozó gyakran egyáltalán  nem
      tudja, hogy mikor lesz újra szabad egy foglalt  memóriarész.
      Ha egy szövegszerkesztô elér  egy file-t, akkor az  egérgomb
      megnyomására a file megnyílik. De azt nem tudjuk, hogy mikor
      lesz  újra  szabaddá  téve.  Ezt  a  programozó  sem   tudja
      vezérelni. Hiszen lehet,  hogy más feladatokon  és ablakokon
      keresztül  valahol  hivatkoznak ugyanerre  a  file-ra. Tehát
      szükség   van   egy   központi   irányítóra,   amely   képes
      meghatározni,  hogy él-e  még valahol  hivatkozás a  file-ra
      vagy sem. Ez a szemétgyûjtô (garbage collector). A  memóriát
      teljességében kell irányítani.  Éppúgy, ahogy egy  allokátor
      irányítja a teljes lemezmemóriát.
          @K--   A   szemétgyûjtô   az   Oberon    objektumorientált
      @Kfelépítésének következménye?@N
          --  Igen,  ha  az  ""objektumorientált"  jelzôt  nem   a
      típushoz   kötött  metódusok   sajátos  értelmében   értjük.
      Egyébként  is  hasznos  lenne  használni  a  szemétgyûjtést.
      Minden objektumnak van  típusa, és a  szemétgyûjtônek minden
      esetben   információt   kell  nyújtania   a   típusokról  az
      együttmûködéshez.  Tudnia  kell,  hogy  mi  használható  fel
      szabadon, vannak-e további kapcsolatok és így tovább. Ez nem
      lehetséges     megbízható     típusrendszer     nélkül.    A
      memóriavezérlés így védve  van a lerobbanástól  és könnyedén
      kezelhetô.
          @K--   Mi   a   helyzet   az   egyes   objektumok  közötti
      @Kbiztonsággal? El vannak egymástól szigetelve az  objektumok,
      @Kvagy lehetséges közöttük az együttmûködés?@N
          -- Ez nem lehetséges -- ha az Oberon-nyelvben  maradunk.
      Bizonyos  modulokat  kódolhatunk  assemblyben  is,  de   ezt
      senkinek sem  ajánlom. A  legalsó szinten  az objektumokat a
      hatékonyság   érdekében   assemblyben   programoztuk.  Ettôl
      eltekintve   az    együttmûködés   a    nyelvben   definiált
      csatlakozásokra korlátozódik.
          @K--   Az   Oberon   már   a   negyedik   nyelv,  amelynek
      @Kfejlesztésében Ön irányadó módon vett részt. Miért kutatja a
      @Ktökéletes programozási nyelvet?@N
          -- A programozási nyelv egy formai jelölésmód. Az a szó,
      hogy   ""nyelv"   tulajdonképpen   hibás   megnevezés.   Nem
      Oberonban, nem Pascalban beszélünk, hanem formailag fejezzük
      ki a  programokat. Hogy  miért csinálom  ezt újra  meg újra?
      Tulajdonképpen azért, mert  mérnökként mindig is  érdekelt a
      számítógépes rendszerek, operációs rendszerek, compilerek és
      grafikai  rendszerek   létrehozása.  És   tanárként  nemcsak
      rendszereket  akarok  készíteni,  hanem  meg  akarom   tudni
      jeleníteni  és   magyarázni  ôket.   Ezért  érthetôen   kell
      dokumentálni ezeket, olyan absztrakt módon, amely  világosan
      megfogalmazott szabályokon nyugszik. Ezért égetô szükség van
      egy alkalmas formarendszer létrehozására.
          Korábban nem volt ilyen, vagy legalábbis nem volt az  én
      számomra kielégítô formarendszer. 1960-ban láttam  munkához.
      A Fortran kétségtelenül nem volt kielégítô, az assembly  kód
      még  kevésbé   volt  az.   Az  ezt   követô  harminc   évben
      fejlesztéseink sokkal  bonyolultabbá és  sokszínûbbé váltak.
      Az  általam  definiált  nyelvek  ugyanis  nem  különülnek el
      egymástól,  hanem fejlôdési  sort képeznek.  Az Algol  W-vel
      kezdtem, aztán következett a Pascal, a Modula, majd pedig az
      Oberon. A Pascalban a lényeges többletet az adatstrukturálás
      jelentette, a  Modulában a  modulok használata  és talán  az
      információrejtés, az Oberonban pedig a típusfogalom teljessé
      tétele és a típusbôvítés.
          @K-- Mi következik az Oberon után?@N
          -- Nem akarom ebben  az irányban folytatni a  munkát. Az
      embernek  valahol  meg  kell húznia  a  határt.  Ez nem  azt
      jelenti,   hogy  teljesen   el  akarok   fordulni  ettôl   a
      területtôl.  Most  a  párhuzamos  rendszerek  és  az osztott
      rendszerek jelentenek  számomra kihívást.  Ezen a  területen
      még  nem  találták  meg az  ideális  formarendszert.  És nem
      totális  forradalom  várható,  hanem  fontos   elôrelépések.
      Elôször a valóban alapvetô formai rendszert kell kidolgozni,
      ami sok problémát vet fel.
          @K-- Melyek ezek a problémák?@N
          -- Természetesen  már sok  osztott rendszer  létezik, de
      ezek barkácsmunkák. Nem lehet bennük assemblyben vagy  C-ben
      programozni,  ahogy  az  általában  szokásos.  Nem  olyan  a
      szituáció, ahogy  egy tudós  le szeretné  írni egy könyvben,
      hanem   meg   kell   fejteni   a   titokzatos,   szövevényes
      programszövegeket.  Én  szeretném  világosan  megmutatni   a
      koncepciókat,  és  csak  azután  megmutatni,  hogy  hol kell
      bôvíteni.  Nem  pedig  fordítva.  Ha  Önök  egyszer megnézik
      ezeket   a   C-ben   írt   programszöveg-útvesztôket,  akkor
      belátják,  hogy  valóban  pokoli  nagy  feladat  kitalálni a
      lényeget. Kivéve akkor, ha pont ott van a szerzôjük.
          @K-- Mi a véleménye a Smalltalkról?@N
          --  A   Smalltalkkal  1976/77-ben   ismerkedtem  meg   a
      Xeroxnál. Számomra egyszerûen  nem volt tiszta  nyelv. Nincs
      matematikai alapokon megmagyarázható, világos koncepciója. A
      Smalltalk kézikönyve körülbelül  négyszáz oldalas --  ez már
      jelzi, hogy valami nem stimmel. A Smalltalkkal mint nyelvvel
      csak rossz tapasztalataim  vannak. De ez  a nyelv emelte  ki
      elôször az  objektumorientált megközelítésmódot,  ami valódi
      többletet jelentett. Ez egyébként rejtve már a Simulában  is
      benne volt. A Smalltalk az egymást átfedô ablakai miatt vált
      ismertté.
          A Smalltalkot a kezelési  felülete tette híressé, s  nem
      maga a  nyelv. Akkor  óriási hatással  volt rám,  de ma  már
      tudjuk,  hogy  ezek a  technikák  átvihetôk tetszôleges  más
      programnyelvekbe.
          Számomra nem tûnik hatékonynak egy olyan nyelv, amelyben
      mindent  objektumorientáltan   kell  megcsinálni   (ilyen  a
      Smalltalk). A  következô példát  mindig szívesen  hozom fel:
      megtanultuk,  hogy   összeadhatunk  két   egyenjogú  számot:
      3+4=4+3. Ez a  kommutativitás törvénye. Azonban  a Smalltalk
      objektumorientált  világában  el  kell  döntenünk,  hogy   a
      ""3"-at objektumnak tekintjük, és küldünk neki egy üzenetet,
      hogy ""Adj hozzá önmagadhoz négyet". Tehát ""három",  ""+4".
      A  ""négy",  ""+3" mûveletet  (ami  ugyanazt eredményezi,  a
      kommutativitás miatt),  Smalltalkban egy  másik objektum,  a
      ""négy",  és  egy  másik  üzenet,  a  ""+3"  valósítja  meg.
      Smalltalkban nincs kommutativitás.
          Sok jó és megalapozott ok van arra, hogy miért nem lenne
      jó   félretolni   a   matematikát.   Az    objektumorientált
      programozásban      viszont      néha       rákényszerülünk.
      Objektumorientált  technikákra  van  szükségünk  a  kezelési
      felületeknél -- de nem mindig és mindenütt.
          @K--  Åt  lehet   vinni  az  operációs   rendszer  nélküli
      @Kcompilert egy másik operációs rendszerre?@N
          -- Az Oberon  csak akkor nyújtja  valódi lényegét, ha  a
      teljes rendszert implementáljuk. Különben nem sok  választja
      el a Modulától. Akkor már nem éri meg a fáradságot. A háttér
      is   idetartozik:    nyelv   és    rendszer   --    központi
      memóriavezérlôvel.
          @K--  Alkalmassá  tehetô  a  teljes  rendszer kereskedelmi
      @Kforgalmazásra?@N
          -- Igen,  úgy, hogy  egy meglévô  rendszerre építjük. Az
      egyetlen hátránya az, hogy a régi operációs rendszert még  a
      központi   memóriában   kell   tartani.   Az   Oberon    nem
      használhatja,  békén  hagyja ezt  a  memóriarészt. Ezenkívül
      azonban nincs más hátrány.
          @K--  Milyenek  voltak  a  kollégák  és  a  számítógépipar
      @Kvisszajelzései?@N
          --  Az ipar  eddig alig  mutatott érdeklôdést.  Svájcban
      egyáltalán  nem,  hiszen  ott  aligha  lehet komputeriparról
      beszélni. Fô célunk az, hogy új ötleteket mutassunk be.  Nem
      akarjuk feltétlenül  világszerte elterjeszteni  a rendszert.
      Szép   lenne,  ha   ez  megtörténne,   de  ez   csak   mások
      közremûködésével lehetséges. Nekünk ugyanis nincs cégünk, és
      nincs  is  közvetlen  hasznunk  belôle.  Pusztán  az ötletet
      tudjuk terjeszteni.
          @K-- És milyenek voltak a visszajelzések?@N
          --  Talán még  túl korai  lenne ezt  megítélni. Még  nem
      érkezett sok visszajelzés. A legtöbben lelkesek az ötlettôl,
      de a legtöbb kritikát teljesen jelentéktelen dolgok  kapták.
      Kaptunk  nagyon  konstruktív megjegyzéseket  is.  Hiszen kit
      érdekel egy új  operációs rendszer, függetlenül  attól, hogy
      jó, rossz vagy szuperjó  vagy tartalmaz-e új ötleteket?  Épp
      ellenkezôleg, az új ötletek néha akaratlanul jönnek,  amikor
      valami újat kell tanulni.
          @K--  De  mindenki tudja  a  meglévô operációs  rendszerek
      @Khiányosságait.@N
          --  Az  emberek azonban  nem  változnak. Megtanulják  az
      MS-DOS-t,  és   ennyi  az   egész.  A   továbblépést  erôsen
      akadályozza  a  megszokás   hatalma.  Ezért  lenne   jó,  ha
      mindenekelôtt az egyetemek  segítenének megismertetni az  új
      ötleteket. A Borland ezt tette a Pascallal.
          @K-- Melyek  voltak a  lényeges változások  eddigi munkája
      @Ksorán?@N
          --  Az  egyik  fordulópont  1976/77-ben  volt,  amikor a
      Xeroxnál   láttam   a   személyi   munkaállomásokat.   Akkor
      elhatároztam, hogy itt  Zürichben építek egy  munkaállomást.
      Másik  fordulópont  volt számomra  a  hardver irányába  való
      eltolódás és egy olyan rendszer koncepciója, amelynek  közös
      a hardvere és szoftvere.
          A programnyelvek mindig úgymond mellékesen fejlôdtek ki.
      Sosem  mondtam azt,  hogy most  kifejlesztem a  Modula--2-t,
      hanem a Modula--2 vált szükségessé, mivel kellett egy  nyelv
      a Lilith rendszerhez. Vagy  az Oberonra volt szükség,  mivel
      kellett  egy  nyelv  az  Oberon  rendszerhez.  Elôször ugyan
      Modulában  akartuk  megírni, de  aztán  láttuk, hogy  valami
      egészen  lényeges  hiányzik:   a  teljesebb  típusok   és  a
      típusbôvítés.  Egy  nyelv  kifejlesztése  sohasem  volt   az
      elsôdleges célunk.

      @KAz interjút Robert Grimm és Eva Weber készítette.@N


      @VNiklaus Wirth@N

          Niklaus   Wirth   az   egyik   legjelentôsebb    európai
      informatikus.  Az általa  kifejlesztett Pascal  programnyelv
      döntô hatással volt a modern programozók munkastílusára.
          A   svájci   származású   tudós   1958-ban   fejezte  be
      villamosmérnöki  tanulmányait a  zürichi Szövetségi  Mûszaki
      Fôiskolán,  és  két  évvel  késôbb  Kanadában  a  tudományok
      doktora lett.  Wirth 1963-ban  szerezte meg  bölcsészdoktori
      címét a híres  kaliforniai Berkeley Egyetemen.  Négy további
      évig  tanított  segédprofesszorként  a  kaliforniai Stanford
      Egyetemen.  Ott  fejlesztette  ki  a  PL360  és  az  Algol W
      programnyelveket. Wirth  professzor 1968-ban  átszerzôdött a
      zürichi  ETH  intézetbe,  ahol  kidolgozta  a  Pascalt  és a
      Modulát. Az  elmúlt öt  év során  Niklaus Wirth  -- intézeti
      kollégájával, Jürg Gutknechttel együtt -- kifejlesztette  az
      Oberon rendszert.

          @VIrodalom:@N Martin Reiser:  The Oberon System.  User Guide
      and Programmer's Manual (Az Oberon-rendszer. Felhasználói és
      programozói  kézikönyv).  Kiadó:  Addison-Wesley  Publishing
      Company, 1991.